


Pokemon Cipher Intel

by WAR10CKcrimsondemon



Category: Pocket Monsters | Pokemon (Main Video Game Series)
Genre: Gen, Security, cipher, encryption, pokemon team cipher
Language: English
Status: Completed
Published: 2019-04-30
Updated: 2019-04-30
Packaged: 2020-02-10 08:47:19
Rating: General Audiences
Warnings: No Archive Warnings Apply
Chapters: 4
Words: 2,244
Publisher: archiveofourown.org
Story URL: https://archiveofourown.org/works/18657031
Author URL: https://archiveofourown.org/users/WAR10CKcrimsondemon/pseuds/WAR10CKcrimsondemon
Summary: A series of documents written by an analyst working with the main protagonist of the game as he works on trying to understand the security of Cipher, the criminal organization involved in the unethical Shadow Pokemon research and creation.





	1. A DataROM and Laptop has been recovered.

**Author's Note:**

> WARNING: This contains a lot of techno jargon.
> 
> The security might seem tight and unreasonable but considering the amount of paranoia that is present in a criminal organization, especially one performing clandestine research of the illegal kind, extremely tight security is most likely justified.

Poke Log NO: 12.526.65

One of our best trainers just got back from infiltrating the Cipher Shadow Pokemon Research Lab. After defeating a Cipher Admin he brought back a Data ROM and a laptop for analysis. He said he couldn’t read any of the contents.

We looked into this Data ROM and found some files of interest:

CIPHER_OPS_SHDW_PKMN_DES_LAB.ENC  
CIPHER_OPS_SHDW_PKMN_KEY.ENC  
CIPHER_OPS_SHDW_PKMN_CTDRK_ISLE.ENC  
CIPHER_OPS_SHDW_PKMN_RES_XD001.ENC

These files appear to be encrypted and cannot be read. Looking at them in a Hex Editor, we found the following info in the header:

7Z X-ALPHA_1024_EAX

It appears to be information regarding the encryption. First off they appear to be 7zip archives. But the rest is a mystery

We knew that Cipher has expert cryptographers in their employ so we suspected that they developed some strong encryption algorithms to be used internally. 

Now on to the laptop. 

It looks like a standard laptop but with few interesting things we noticed. There is a slot in the side where a smart card can be inserted. After cloning the hard drive we booted it up. It immediately throws us into a login prompt for a Username, Password, and a Cipher Access Card. We don’t have one of those nor do we have login credentials. A warning on the screen indicates that three failed authentication attempts triggers an automatic wipe of the computer. So this is a dead end.

On the bottom in the corner of the screen the words “CipherBIOS v2.26.4” can be seen. From this we can assume the Cipher developed their own BIOS firmware. The hard drive looks like it uses a Full Disk Encryption system in which even the bootloader is encrypted. We don’t know the algorithms this software uses.

Opening the computer up, we found a few unknown chips. They all appear to be Cipher designed given the “CIPHER” in the part numbers. It looks like that unless we can get some design documents, we cannot unlock this computer.


	2. Cipher Hardware Security Revealed

**Summary for the Chapter:**

> WARNING: This contains a lot of techno jargon.
> 
> Our main protagonist has returned and brought back a DataROM containing all of the details regarding the IT systems for Cipher. The security is extremely tight. Even more so then most government Intelligence Agencies.
> 
> Our analyst goes over the main hardware security measures.

Poke Log NO: 12.534.56

Our primary trainer returned from the Cipher Key Lair. A Data ROM along with the decrypt key was recovered from the place. He said he saw what looked like a computer hardware research lab and factory. 

Decrypting that Data ROM has uncovered the design documents for all Cipher IT Hardware and Software. This is the break we need. Looking at them reveals some key findings.

First, the mysterious X-ALPHA we saw on the other Data ROM from the Lab is indeed an internally developed encryption algorithm. X-ALPHA is a Symmetric Key Block Cipher that uses 256, 512, and 1024 bit keys. It can operate in ECB, CBC, XTS, CFB, OFB, CTR, GCM, CCM, CWC, PCBC, IPAM, OCB, ESSIV, XEX, and EAX modes.

In this case it is using EAX mode for File Encryption and XTS mode for OTF Full Disk Encryption. Also it is using 1024 bit keys. So we are looking for 128 character encryption keys. 

These keys are generated with three things: Username, Password, and some secret values on the Cipher Access Card. These are fed into the Argon2 PBKDF and then hashed with SHA3-512 to create the final 128 byte key. 

Those unknown chips we found are indeed all internally developed by Cipher for their own use. The data contains the complete schematics for all of these chips. They are all Application Specific Integrated Circuits (ASIC) designed to provide hardware enforced security and encryption.

All of these chips contain multiple countermeasures to prevent reverse engineering. Physical tampering with the chip causes it to self destruct. The die is shielded to prevent X-Ray imaging.

Looking at the hard drive schematics, we noticed the first unique chip. This is apparently a Secure Cryptoprocessor developed internally by Cipher to secure their data storage devices. 

Interestingly enough, the key to the drive are not stored permanently. Rather they are kept in a special RAM section of the chip and stored while the drive is in use. The key is then wiped when the drive is not in use. When installed in a Cipher Computer it hooks into something called CipherBIOS.

The chip is used provide hardware accelerated on-the-fly (OTF) encryption and decryption along with secure handling and generation of encryption keys. This makes perfect sense since full disk encryption is extremely slow at first. Benchmarking of the operations of this chip show extremely good results. The chip schematics are provided in this data. It also appears that there are Duel Quantum Random Number Generators built in to the die.

The next one we saw is a TPM chip designed to support Cipher developed algorithms and protocols. This is what enforces that multi-factor authentication. It contains a unique Secure Boot Certificate controlled and signed by Cipher. This ensures that only operating systems specifically approved by Cipher can be run on the computer. The certificate uses an asymmetric encryption system called “CipherTRU PKI” as the document calls it.

Apparently the TPM is also used to control all applications that are allowed to access the main OS. Cipher is using a Walled Garden approach to application development. Only applications and firmware updates signed by Cipher can be installed.

The third one is a dedicated cryptographic co-processor which performs all the encryption/decryption operations for hardware accelerated encryption using the CipherLinux Kernel Cryptographic API. This is used by all Cipher approved applications and operating systems to do cryptographic operations and hooks directly into the CPU. 

The fourth one is an entire Hardware Security Module (HSM) which serves as the network adapter. This one is extremely complicated according to the design documents. It even has what appears to be its own high capacity flash memory chips for data storage. 

The HSM contains an ASIC for using a protocol known as CI2P. This appears to be a internally developed darknet protocol. It is used to connect to a “CipherNet”. There are also references to a “CipherTRU PKI” as well. We will look through the network design documents later. 

These flash memory chips are used to store cryptographic data securely off of the main hard drive and is kept encrypted with X-ALPHA_1024_XTS when not being used. The keys are constructed from the same data used to decrypt the main hard drive along with a unique salt value. This is really clever way to make sure that cloning the hard drive does not compromise the security of their systems.

There is also the presence of a data self-destruction mechanism upon any electronic or physical tampering. This includes breaking the TEMPEST shielding preventing EM Analysis. Also the HSM has a special white-noise generator designed to prevent audio analysis. They really thought of everything.


	3. Cipher's Main Software Security

**Summary for the Chapter:**

> WARNING: This contains a lot of techno jargon.
> 
> Our analyst now examines the software used by Cipher. It is all developed in-house and custom made. Extremely tight security is provided and signs of their fully justified paranoia are becoming more apparent.

The next set of design documents contains the source code for three major pieces of software. All of which are internally developed and constantly updated. They are CipherBIOS, CipherBoot, and CipherLinux.

The CipherBIOS is a specially developed bios designed for security and contains an implementation of Cipher’s X-ALPHA_1024_XTS encryption algorithm to decrypt the hard drive. It also contains a “CipherTRU PKI” enhanced SecureBoot function that cannot be turned off. Also unlike regular BIOS, this one is stored in the TPM and cannot be reset by removing the CMOS Battery. The SecureBoot also applies to external boot media which means that only operating systems approved and signed by Cipher can be installed, run, or even booted on Cipher computers. 

CipherBoot appears to be a Cipher developed fork of the GRUB Bootloader. This is also hooked into the SecureBoot function of the CipherBIOS and at the current time there is only one OS that is allowed on the computer. It is called CipherLinux.

CipherLinux is not just a secure distribution of Linux but an entire fork of the Linux Kernel. It contains its own cryptographic API designed to support all of the Cipher approved encryption algorithms and this “CipherTRU PKI”. It also has SElinux hard coded into the kernel itself. It comes in multiple versions.

There are versions that support Unity, GNOME, KDE, and LXDE. All of them use x64 aka amd64 architecture. There is also mobile/tablet version called CipherMobile and optimized for ARM processors. Also there is CipherLinux for Clients and CipherLinux for Servers.

CipherLinux comes with a built in Auto-Update program which installs all available software updates without user input. This must be to ensure that all devices are not left vulnerable by using out of date operating systems and software. This is really clever on their part. 

All default Cipher developed programs come by default in CipherLinux and are updated via a special APT repo which we do not have access to. In fact, access to this repo requires a special public key that is kept secret. This key is loaded into CipherLinux and saved to the HSM upon connection to something called “CipherNet”. This must be to prevent unauthorized access to it.


	4. Cipher's Network Security

**Summary for the Chapter:**

> WARNING: This contains a lot of techno jargon.
> 
> Our analyst looks into the network security of their computer systems. An entire darknet with custom made protocols has been developed in-house and uses its own encryption system with Quantum Computer Resistant Encryption.

Poke Log NO: 12.534.72

Looking at the next set of design documents revealed what the “CipherTRU PKI” is along with full details of “CipherNet”. 

They are using internal implementation of NTRUEncrypt with pqNTRUsign as the signing algorithm to secure their intranet known as CipherNet. Since NTRU is a lattice/ring based Quantum Resistant Cryptosystem, we are unable to crack it. Even our quantum computer cannot do anything. This implementation is called CipherTRU Public Key Infrastructure (PKI). 

CipherNet is built to provide End To End encryption using an internally developed implementation of the I2P protocol know as Cipher Invisible Intranet Protocol (CI2P). In addition to this, there is also a custom Transport Layer Security (TLS) Protocol for added encryption and access control.

To gain access to the network, we will need to obtain valid Router Keys, the Peer List, the Private Address Book containing all of the local destinations of Cipher EepServers, and the underlying TLS Certs for access to these EepServers. However this will be easier said then done as they have placed all of this in the HSM’s secure flash memory. 

Their TLS protocol consists of the CipherTRU PKI using a hybrid encryption scheme in which 1024 bit X-ALPHA Symmetric Keys are encrypted with the NTRU Public Key and then exchanged. Encryption is then performed using X-ALPHA with Perfect Forward Secrecy (PFS). So even if we do manage to compromise their CipherTRU Keys, we cannot read any past communications or sessions.

Certs use the CipherTRU PKI and are generated with a unique client ID attached to them. We cannot generate our own TLS Certs since Cipher is running their own Self-Signed Certificate Authority (CA) in an unknown location. All Cipher TLS Certs must be signed by the Root CA before the computers they are assigned to are allowed to access CI2P EepServers. No signed cert, no access. So unless we can get the Root Signing Key, that option is off the table. 

The use of the I2P protocol suggests that CipherNet is overlayed on the public internet and we just cannot detect it. This is because all I2P traffic is anonymous and this makes it impossible for us to distinguish CipherNet traffic from any other I2P traffic. The CI2P design documents and source code indicate that the router keys use the CipherTRU PKI which makes them unable to communicate with the rest of the Public I2P network.

Looking through the source code of CipherTRU and CI2P have revealed no weaknesses or exploits that can be used to extract useful information. If we cannot get inside this network then there is no way the police can get inside. 

It appears that their internal mail system is also using high levels of cryptographic protection. It consists of an internally developed application known as CipherMail which interacts securely with the CI2P Protocol. When you run it, it accesses Cipher's Mail EepServers using the local TLS Cert for "[unique client ID].mail.ciphernet.i2p". The Server checks to see if that cert is signed and then prompts for login if this check passes. If not, the application crashes on purpose throwing an ACCESS DENIED error.

What's interesting is that when an email is sent, the recipient's TLS Cert for "[unique client ID].mail.ciphernet.i2p" is used to encrypt message content while the server's TLS Cert is used to encrypt the metadata. When an email reaches the server, the metadata is decrypted and then the encrypted message is sent to the proper inbox where it is then decrypted by the recipient. Also the metadata decryption is done in the background using a method in which the server admin has no idea what the messages say or who the senders and receivers are. The message is then archived on the server in its encrypted form.

This zero knowledge approach conforms to the enforcement of an organizational policy of compartmentalization in which access to systems and information is given strictly on a need to know basis. The policy requires that all information no matter how small or insignificant be kept secret from everyone else who does not need to know. This requires all communications be anonymous to everyone except the people sending and receiving them.

Also interesting is the use of something called CipherBote which appears to be an internal I2PBote implementation. This must be used for high level messages which cannot be trusted to mail servers. This program also provides totally anonymous communications from everyone since there are no servers for I2PBote and it operates as a mixnet. It is likely that NTRU is also being used in this software too.

**Author's Note:**

> I did quite a bit of editing and revising in order to make sure the techno jargon actually made sense to people who understand it. As the story got longer I had to revise multiple paragraphs throughout the work to make sure that inconsistancies were removed. The security measures described in this work are in theory, possible to implement in real life.


End file.
